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Abstract 

This paper demonstrates a few programming tech¬ 
niques for low-latency sample-by-sample audio pro¬ 
gramming. Some of them may not have been used 
for this purpose before. The demonstrated tech¬ 
niques are: Realtime memory allocation, realtime 
garbage collector, storing instrument data implicitly 
in closures, auto-allocated variables, handling signal 
buses using dynamic scoping, and continuation pass¬ 
ing style programming. 
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1 Introduction 

This paper demonstrates how to implement a 
MIDI software synthesizer (MIDI soft synth) 
using some unusual audio programming tech¬ 
niques. The examples are written for Snd-RT 
[Matheussen, 2008], an experimental audio pro¬ 
gramming system supporting these techniques. 
The techniques firstly emphasize convenience 
(i.e. few lines of code, and easy to read and 
modify), and not performance. Snd-RT 1 runs 
on top of Snd 2 which again runs on top of the 
Scheme interpreter Guile. 3 Guile helps gluing 
all parts together. 

It is common in music programming only to 
compute the sounds themselves in a realtime 
priority thread. Scheduling new notes, alloca¬ 
tion of data, data initialization, etc. are usually 
performed in a thread which has a lower prior¬ 
ity than the audio thread. Doing it this way 
helps to ensure constant and predictable CPU 
usage for the audio thread. But writing code 
that way is also more complicated. At least, 
when all samples are calculated one by one. If 

1 http: //archive.notam02.no / arkiv/doc / snd-rt / 

2 http: //ccrma.stanford.edu / software / snd / 

3 http://www.gnu.org/software/guile/guile.html 


however the programming only concerns han¬ 
dling blocks of samples where we only control a 
signal graph, there are several high level alter¬ 
natives which makes it relatively easy to do a 
straightforward implementation of a MIDI soft 
synth. Examples of such high level music pro¬ 
gramming systems are SuperCollider [McCart¬ 
ney, 2002], Pd [Puckette, 2002], CSound 4 and 
many others. 

But this paper does not describe use of block 
processing. In this paper, all samples are in¬ 
dividually calculated. The paper also explores 
possible advantages of doing everything, alloca¬ 
tion, initialization, scheduling, etc., from inside 
the realtime audio thread. 

At least it looks like everything is performed 
inside the realtime audio thread. The under¬ 
lying implementation is free to reorganize the 
code any way it wants, although such reorga¬ 
nizing is not performed in Snd-RT yet. 

Future work is making code using these tech¬ 
niques perform equally, or perhaps even better, 
than code where allocation and initialization of 
data is explicitly written not to run in the real¬ 
time audio thread. 

2 MIDI software synthesizer 

The reason for demonstrating a MIDI soft synth 
instead of other types of music programs such 
as a granular synthesis generator or a reverb, is 
that the behavior of a MIDI soft synth is well 
known, plus that a MIDI soft synth contains 
many common challenges in audio and music 
programming: 

1. Generating samples. To hear sound, we 
need to generate samples at the Audio 
Rate. 

2. Handling Events. MIDI data are read at a 
rate lower than the audio rate. This rate is 
commonly called the Control Rate. 

4 http://www. csound. com 




3. Variable polyphony. Sometimes no notes 
are playing, sometimes maybe 30 notes are 
playing. 

4. Data allocation. Each playing note re¬ 
quires some data to keep track of frequency, 
phase, envelope position, volume, etc. The 
challenges are; How do we allocate memory 
for the data? When do we allocate memory 
for the data? How do we store the memory 
holding the data? When do we initialize 
the data? 

5. Bus routing. The sound coming from the 
tone generators is commonly routed both 
through an envelope and a reverb. In ad¬ 
dition, the tones may be autopanned, i.e. 
panned differently between two loudspeak¬ 
ers depending on the note height (similar 
to the direction of the sound coming from 
a piano or a pipe organ). 

3 Common Syntax for the Examples 

The examples are written for a variant of 
the programming language Scheme [Steele and 
Sussman, 1978]. Scheme is a functional lan¬ 
guage with imperative operators and static 
scoping. 

A number of additional macros and special 
operators have been added to the language, and 
some of them are documented here because of 
the examples later in the paper. 

(<rt-stalin>...) is a macro which first trans¬ 
forms the code inside the block into clean 
R4RS code [Clinger and Rees, 1991] un¬ 
derstood by the Stalin Scheme compiler. 5 
(Stalin Scheme is an R4RS compiler). Af¬ 
ter Stalin is finished compiling the code, the 
produced object file is dynamically linked 
into Snd-RT and scheduled to immediately 
run inside the realtime audio thread. 

(define-stalin signature ...) defines variables 
and functions which are automatically in¬ 
serted into the generated Stalin scheme 
code if needed. The syntax is similar to 
define. 

(spawn ...) spawns a new coroutine [Conway, 
1963; Dahl and Nygaard, 1966]. Corou¬ 
tines are stored in a priority queue and it is 
not necessary to explicitly call the spawned 

5 Stalin - a STAtic Language ImplementatioN, 
http://cobweb.ecn.purdue.edu/ qobi/software.html. 


coroutine to make it run. The spawned 
coroutine will run automatically as soon 6 
as the current coroutine yields (by calling 
yield or wait), or the current coroutine 
ends. 

Coroutines are convenient in music pro¬ 
gramming since it often turns out practi¬ 
cal to let one dedicated coroutine handle 
only one voice, instead of mixing the voices 
manually. Furthermore, arbitrarily placed 
pauses and breaks are relatively easy to im¬ 
plement when using coroutines, and there¬ 
fore, supporting dynamic control rate simi¬ 
lar to ChucK [Wang and Cook, 2003] comes 
for free. 

(wait n) waits n number of frames before con¬ 
tinuing the execution of the current corou¬ 
tine. 

(sound ...) spawns a special kind of coroutine 
where the code inside sound is called one 
time per sample. (sound coroutines are 
stored in a tree and not in a priority queue 
since the order of execution for sound 
coroutines depends on the bus system and 
not when they are scheduled to wake up.) 

A simple version of the sound macro, 
called my-sound, can be implemented like 
this: 

(define-stalin-macro (my-sound . body) 

‘(spawn 

(while #t 
,©body 
(wait 1)))) 

However, my-sound is inefficient compared 
to sound since my-sound is likely to do 
a coroutine context switch at every call 
to wait. 7 sound doesn’t suffer from this 
problem since it is run in a special mode. 
This mode makes it possible to run tight 
loops which does not cause a context switch 
until the next scheduled event. 

(out <.channel> sample) sends out data to 
the current bus at the current time, (the 
current bus and the current time can be 
thought of as global variables which are im¬ 
plicitly read from and written to by many 

6 Unless other coroutines are placed earlier in the 
queue. 

7 I.e. if two or more my-sound blocks or sound blocks 
run simultaneously, and at least one of them is a my- 
sound block, there will be at least two coroutine context 
switches at every sound frame. 




operators in the system) 8 By default, the 
current bus is connected to the sound card, 
but this can be overridden by using the 
in macro which is explained in more de¬ 
tail later. 

If the channel argument is omitted, the 
sample is written both to channel 0 and 1. 

It makes sense only to use out inside a 
sound block. The following example plays 
a 400Hz sine sound to the sound card: 

(<rt-stalin> 

(let ((phase 0.0)) 

(sound 

(out (sin phase)) 

(inc! phase (hz->radians 400))))) 

(range varname start end ...) is a simple lo¬ 
op iterator macro which can be imple¬ 
mented like this: 9 

(define-macro (range varname start end . body) 
(define loop (gensym)) 

‘(let ,loop ((,varname ,start)) 

(cond ((<,var , end) 

,©body 

(,loop (+ ,varname 1)))))) 

(wait-midi : options ...) waits until MIDI data 
is received, either from an external inter¬ 
face, or from another program. 

wait-midi has a few options to specify the 
kind of MIDI data it is waiting for. In the 
examples in this paper, the following op¬ 
tions for wait-midi are used: 

■.command note-on 

Only wait for a note on MIDI message. 

■.command note-off 

Only wait for a note off MIDI mes¬ 
sage. 

■.note number 

Only wait for a note which has MIDI 
note number number. 

Inside the wait-midi block we also have 
access to data created from the incom¬ 
ing midi event. In this paper we use 
(midi-vol) for getting the velocity (con¬ 
verted to a number between 0.0 and 1.0), 
and (midi-note) for getting the MIDI 
note number. 

8 Internally, the current bus is a coroutine-local vari¬ 
able, while the current time is a global variable. 

9 The actual implementation used in Snd-RT also 

makes sure that “end” is always evaluated only one time. 


:where is just another way to declare local 
variables. For example, 

(+ 2 b 

:where b 50) 

is another way of writing 

(let c (b 50)) 

(+ 2 b)) 

There are three reason for using :where 
instead of let. The first reason is that 
the use of :where requires less parenthe¬ 
sis. The second reason is that reading the 
code sometimes sounds more natural this 
way. (I.e “add 2 and b, where b is 50” in¬ 
stead of “let b be 50, add 2 and b”.) The 
third reason is that it’s sometimes easier 
to understand the code if you know what 
you want to do with a variable, before it is 
defined. 

4 Basic MIDI Soft Synth 

We start by showing what is probably the sim¬ 
plest way to implement a MIDI soft synth: 

(range note-num 0 128 

(<rt-stalin> 

(define phase 0.0) 

(define volume 0.0) 

(sound 

(out (* volume (sin phase)))) 

(inc! phase (midi->radians note-num))) 
(while #t 

(wait-midi :command note-on mote note-num 
(set! volume (midi-vol))) 

(wait-midi :command note-off mote note-num 
(set! volume 0.0)))) 

This program runs 128 instruments simul¬ 
taneously. Each instrument is responsible for 
playing one tone. 128 variables holding volume 
are also used for communicating between the 
parts of the code which plays sound (running at 
the audio rate), and the parts of the code which 
reads MIDI information (running at the control 
rate 10 ). 

There are several things in this version which 
are not optimal. Most important is that you 

10 Note that the control rate in Snd-RT is dynamic, 
similar to the music programming system ChucK. Dy¬ 
namic control rate means that the smallest available 
time-difference between events is not set to a fixed num¬ 
ber, but can vary. In ChucK, control rate events are 
measured in floating numbers, while in Snd-RT the mea¬ 
surement is in frames. So In Chuck, the time difference 
can be very small, while in Snd-RT, it can not be smaller 
than 1 frame. 




would normally not let all instruments play all 
the time, causing unnecessary CPU usage. You 
would also normally limit the polyphony to a 
fixed number, for instance 32 or 64 simultane¬ 
ously sounds, and then immediately schedule 
new notes to a free instrument, if there is one. 

5 Realtime Memory Allocation 

As mentioned, everything inside <_rt-staling 
runs in the audio realtime thread. Allocating 
memory inside the audio thread using the OS al¬ 
location function may cause surprising glitches 
in sound since it is not guaranteed to be an 
0(1) allocator, meaning that it may not al¬ 
ways spend the same amount of time. There¬ 
fore, Snd-RT allocates memory using the Rol- 
lendurchmesserzeitsammler [Matheussen, 2009] 
garbage collector instead. The memory alloca¬ 
tor in Rollendurchmesserzeitsammler is not only 
running in 0(1), but it also allocates memory 
extremely efficiently. [Matheussen, 2009] 

In the following example, it’s clearer that in¬ 
strument data are actually stored in closures 
which are allocated during runtime. 11 In ad¬ 
dition, the 128 spawned coroutines themselves 
require some memory which also needs to be 
allocated: 

(<rt-stalin> 

(range note-mim 0 128 
(spawn 

(define phase 0.0) 

(define volume 0.0) 

(sound 

(out (* volume (sin phase)))) 

(inc! phase (midi->radians note-num))) 

(while #t 

(wait-midi :command note-on mote note-num 
(set! volume (midi-vol))) 

(wait-midi :command note-off mote note-num 
(set! volume 0.0))))) 

6 Realtime Garbage Collection. 
(Creating new instruments only 
when needed) 

The previous version of the MIDI soft synth did 
allocate some memory. However, since all mem¬ 
ory required for the lifetime of the program were 
allocated during startup, it was not necessary to 
free any memory during runtime. 

But in the following example, we simplify the 
code further by creating new tones only when 
they are needed. And to do that, it is necessary 

n Note that memory allocation performed before any 
sound block can easily be run in a non-realtime thread 
before scheduling the rest of the code to run in realtime. 
But that is just an optimization. 


to free memory used by sounds not playing 
anymore to avoid running out of memory. 
Luckily though, freeing memory is taken care 
of automatically by the Rollendurchmesserzeit¬ 
sammler garbage collector, so we don’t have 
to do anything special: 

11 (define-stalin (softsynth) 

2 I (while #t 

31 (wait-midi :command note-on 

41 (define osc (make-oscil :freq (midi->hz (midi-note)))) 

51 (define tone (sound (out (* (midi-vol) (oscil osc))))) 

6 I (spawn 

71 (wait-midi :command note-off :note (midi-note) 

81 (stop tone)))))) 

91 

101 (<rt-stalin> 

111 (softsynth)) 

In this program, when a note-on message is 
received at line 3, two coroutines are scheduled: 

1. A sound coroutine at line 5. 

2. A regular coroutine at line 6. 

Afterwards, the execution immediately jumps 
back to line 3 again, ready to schedule new 
notes. 

So the MIDI soft synth is still polyphonic, 
and contrary to the earlier versions, the CPU 
is now the only factor limiting the number of 
simultaneously playing sounds. 12 

7 Auto-Allocated Variables 

In the following modification, the 
CLM [Schottstaedt, 1994] oscillator oscil 
will be implicitly and automatically allocated 
first time the function oscil is called. After 
the generator is allocated, a pointer to it is 
stored in a special memory slot in the current 
coroutine. 

Since oscil is called from inside a sound 
coroutine, it is natural to store the generator in 
the coroutine itself to avoid all tones using the 
same oscillator, which would happen if the auto- 
allocated variable had been stored in a global 
variable. The new definition of softsynth now 
looks like this: 

(define-stalin (softsynth) 

(while #t 

(wait-midi :command note-on 
(define tone 

(sound (out (* (midi-vol) 

(oscil :freq (midi->hz (midi-note))))))) 

(spawn 

(wait-midi :commend note-off inote (midi-note) 

(stop tone)))))) 


12 Letting the CPU be the only factor to limit 
polyphony is not necessarily a good thing, but doing so 
in this case makes the example very simple. 




The difference between this version and the 
previous one is subtle. But if we instead look 
at the reverb instrument in the next section, it 
would span twice as many lines of code, and the 
code using the reverb would require additional 
logic to create the instrument. 

8 Adding Reverb. (Introducing 
signal buses) 

A MIDI soft synth might sound unprofessional 
or unnatural without some reverb. In this ex¬ 
ample we implement John Chowning’s reverb 13 
and connect it to the output of the MIDI soft 
synth by using the built-in signal bus system: 

(define-stalin (reverb input) 

(delay :size (* .013 (mus-srate)) 

(+ (comb :scaler 0.742 :size 9601 allpass-composed) 

(comb :scaler 0.733 :size 10007 allpass-composed) 

(comb :scaler 0.715 :size 10799 allpass-composed) 

(comb :scaler 0.697 :size 11597 allpass-composed) 

:where allpass-composed 
(send input :through 

(all-pass :feedback -0.7 :feedforward 0.7) 

(all-pass :feedback -0.7 :feedforward 0.7) 

(all-pass :feedback -0.7 :feedforward 0.7) 

(all-pass :feedback -0.7 :feedforward 0.7))))) 

(define-stalin bus (make-bus)) 

(define-stalin (softsynth) 

(while #t 

(wait-midi :command note-on 
(define tone 
(sound 

(write-bus bus 

(* (midi-vol) 

(oscil :freq (midi->hz (midi-note))))))) 

(spawn 

(wait-midi :command note-off inote (midi-note) 

(stop tone)))))) 

(define-stalin (fx-ctrl input clean wet processor) 

(+ (* clean input) 

(* wet (processor input)))) 

(<rt-stalin> 

(spawn 

(softsynth)) 

(sound 

(out (fx-ctrl (read-bus bus) 

0.5 0.09 
reverb)))) 

Signal buses are far from being an “unusual 
technique”, but in text based languages they 
are in disadvantage compared to graphical mu¬ 
sic languages such as Max [Puckette, 2002] or 
Pd. In text based languages it’s inconvenient to 
write to buses, read from buses, and most im¬ 
portantly; it’s hard to see the signal flow. How¬ 
ever, signal buses (or something which provides 

13 as implemented by Bill Schottstaedt in the file 
”jc-reverb.scm” included with Slid. The fx-ctrl function 
is a copy of the function fxctrl implemented in Faust’s 
Freeverb example. 


similar functionality) are necessary, so it would 
be nice to have a better way to handle them. 

9 Routing Signals with Dynamic 
Scoping. (Getting rid of manually 
handling sound buses) 

A slightly less verbose way to create, read and 
write signal buses is to use dynamic scoping 
to route signals. The bus itself is stored in a 
coroutine-local variable and created using the 
in macro. 

Dynamic scoping comes from the fact that 
out writes to the bus which was last set up 
by in. In other words, the scope for the 
current bus (the bus used by out) follows 
the execution of the program. If out isn’t 
(somehow) called from in, it will instead write 
to the bus connected to the soundcard. 

For instance, instead of writing: 

(define-stalin bus (make-bus)) 

(define-stalin (instrl) 

(sound (write-bus bus 0.5))) 

(define-stalin (instr2) 

(sound (write-bus bus -0.5))) 

(<rt-stalin> 

(instrl) 

(instr2) 

(sound 

(out (read-bus bus)))) 

we can write: 

(define-stalin (instrl) 

(sound (out 0.5))) 

(define-stalin (instr2) 

(sound (out -0.5))) 

(<rt-stalin> 

(sound 

(out (in (instrl) 

(instr2))))) 

What happened here was that the first time 
in was called in the main block, it spawned a 
new coroutine and created a new bus. The new 
coroutine then ran immediately, and the first 
thing it did was to change the current bus to 
the newly created bus. The in macro also made 
sure that all sound blocks called from within 
the in macro (i.e. the ones created in instrl and 
instr2 ) is going to run before the main sound 
block. (That’s how sound coroutines are stored 
in a tree) 

When transforming the MIDI soft synth to 
use in instead of manually handling buses, it 
will look like this: 






;; <The reverb instrument is unchanged> 

;; Don’t need the bus anymore: 

(dof ino - otalin buo — (malco - buo)) 

;; softsynth reverted back to the previous version: 

(define-stalin (softsynth) 

(while #t 

(wait-midi :command note-on 
(define tone 

(sound (out (* (midi-vol) 

(oscil :freq (midi->hz (midi-note))))))) 

(spawn 

(wait-midi :command note-off :note (midi-note) 

(stop tone)))))) 

;; A simpler main block: 

(<rt-stalin> 

(sound 

(out (fx-ctrl (in (softsynth)) 

0.5 0.09 
reverb)))) 

10 CPS Sound Generators. (Adding 
stereo reverb and autopanning) 

Using coroutine-local variables was convenient 
in the previous examples. But what happens 
if we want to implement autopanning and (a 
very simple) stereo reverb, as illustrated by the 
graph below? 


+— reverb -> out ch 0 

/ 

softsynth—< 

\ 

+— reverb -> out ch 1 

First, lets try with the tools we have used so 
far: 

(define-stalin (stereo-pan input c) 

(let* ((sqrt2/2 (/ (sqrt 2) 2)) 

(angle (- pi/4 (* c pi/2))) 

(left (* sqrt2/2 (+ (cos angle) (sin angle)))) 

(right (* sqrt2/2 (- (cos angle) (sin angle))))) 

(out 0 (* input left)) 

(out 1 (* input right)))) 

(define-stalin (softsynth) 

(while #t 

(wait-midi :command note-on 
(define tone 
(sound 

(stereo-pan (* (midi-vol) 

(oscil :freq (midi->hz (midi-note)))) 
(/ (midi-note) 127.0)))) 

(spawn 

(wait-midi :command note-off :note (midi-note) 

(stop tone)))))) 

(<rt-stalin> 

(sound 

(in (softsynth) 

(lambda (sound-left sound-right) 

(out 0 (fx-ctrl sound-left 0.5 0.09 reverb)) 

(out 1 (fx-ctrl sound-right 0.5 0.09 reverb)))))) 

At first glance, it may look okay. But 
the reverb will not work properly. The rea¬ 
son is that auto-generated variables used for 
coroutine-local variables are identified by their 
position in the source. And since the code 
for the reverb is written only one place in the 


source, but used two times from the same corou¬ 
tine, both channels will use the same coroutine- 
local variables used by the reverb; a delay, four 
comb filters and four all-pass filters. 

There are a few ways to work around this 
problem. The quickest work-around is to re¬ 
code ’reverb’ into a macro instead of a function. 
However, since neither the problem nor any so¬ 
lution to the problem are very obvious, plus that 
it is slower to use coroutine-local variables than 
manually allocating them (it requires extra in¬ 
structions to check whether the data has been 
allocated 14 ), it’s tempting not to use coroutine- 
local variables at all. 

Instead we introduce a new concept called 
CPS Sound Generators, where CPS stands for 
Continuation Passing Style. [Sussman and 
Steele, 1975] 


10.1 How it works 

Working with CPS Sound Generators are simi¬ 
lar to Faust’s Block Diagrams composition. [Or- 
larey et al., 2004] A CPS Sound Generator can 
also be seen as similar to a Block Diagram in 
Faust, and connecting the CPS Sound Genera¬ 
tors is quite similar to Faust’s Block Diagram 
Algebra (BDA). 

CPS Sound Generators are CPS functions 
which are able to connect to other CPS Sound 
Generators in order to build up a larger function 
for processing samples. The advantage of build¬ 
ing up a program this way is that we know what 
data is needed before starting to process sam¬ 
ples. This means that auto-allocated variables 
don’t have to be stored in coroutines, but can 
be allocated before running the sound block. 

For instance, the following code is written in 
generator-style and plays a 400Hz sine sound to 
the sound card: 


(let ((Generator (let ((osc (make-oscillator 
(lambda (kont) 

(kont (oscil osc)))))) 


(sound 

(Generator (lambda (sample) 

(out sample))))) 


:freq 400))) 


The variable kont in the function Generator 
is the continuation, and it is always the last ar¬ 
gument in a CPS Sound Generator. A continua¬ 
tion is a function containing the rest of the pro¬ 
gram. In other words, a continuation function 

14 It is possible to optimize away these checks, but 
doing so either requires restricting the liberty of the 
programmer, some kind of JIT-compilation, or doing a 
whole-program analysis. 




will never return. The main reason for program¬ 
ming this way is for generators to easily return 
more than one sample, i.e have more than one 
output. 15 

Programming directly this way, as shown 
above, is not convenient, so in order to make 
programming simpler, some additional syntax 
have been added. The two most common oper¬ 
ators are Seq and Par, which behave similar to 
the and infix operators in Faust. 16 

Seq creates a new generator by connecting gen¬ 
erators in sequence. In case an argument is 
not a generator, a generator will automat¬ 
ically be created from the argument. 

For instance, (Seq (+ 2)) is the same as 
writing 

(let ((generator!) (lambda (argl kontO) 

(kontO (+ 2 argl))))) 

(lambda (input0 kontl) 

(generatorO inputO kontl))) 

and (Seq (+ (random 1.0)) (+ 1)) is the 
same as writing 

(let ((generatorO (let ((argO (random 1.0))) 

(lambda (argl kontO) 

(kontO (+ argO argl))))) 
(generatorl (lambda (argl kontl) 

(kontl (+ 1 argl))))) 

(lambda (input kont2) 

(generatorO input (lambda (resultO) 

(generatorl resultO kont2))))) 

;; Evaluating ((Seq (+ 2) (+ 1)) 3 display) 

;; will print 6! 

Par creates a new generator by connecting gen¬ 
erators in parallel. Similar to Seq, if an 
argument is not a generator, a generator 
using the argument will be created auto¬ 
matically. 

For instance, (Par (+ (random 1.0)) (+ 1)) 
is the same as writing: 

(let ((generatorO (let ((argO (random 1.0))) 

(lambda (argl kontO) 

(kontO (+ argO argl))))) 
(generatorl (lambda (argl kontl) 

(kontl (+ 1 argl))))) 

(lambda (input2 input3 kontl) 

(generatorO input2 
(lambda (resultO) 

(generatorl input3 
(lambda (resultl) 

(kontl resultO resultl))))))) 

;; Evaluating ((Par (+ 2)(+ 1)) 3 4 +) will return 10! 


15 Also note that by inlining functions, the Stalin 
scheme compiler is able to optimize away the extra syn¬ 
tax necessary for the CPS style. 

16 Several other special operators are available as well, 
but this paper is too short to document all of them. 


(gen-sound :options generator) is the same 
as writing 

(let ((gen generator)) 

(sound :options 

(gen (lambda (resultO) 

(out 0 resultO))))) 

...when the generator has one output. If 
the generator has two outputs, it will look 
like this: 

(let ((gen generator)) 

(sound :options 

(gen (lambda (resultO resultl) 

(out 0 resultO) 

(out 1 resultl))))) 

...and so forth. 

The Snd-RT preprocessor knows if a variable 
or expression is a CPS Sound Generator by 
looking at whether the first character is capitol. 
For instance, (Seq (Process 2)) is equal to 
(Process 2), while (Seq (process 2)) is equal to 
(lambda (input kont) (kont (process 2 input))), 
regardless of how ’Process’ and ’process’ are 
defined. 

10.2 Handling auto-allocated variables 

oscil and the other CLM generators are macros, 
and the expanded code for (oscil :freq 4-4-0) looks 
like this: 

(oscil_ (autovar (make_oscil_ 440 0.0)) 0 0) 

Normally, autovar variables are translated 
into coroutine-local variables in a separate step 
performed after macro expansion. However, 
when an auto-allocated variable is an argu¬ 
ment for a generator, the autovar surrounding 
is removed. And, similar to other arguments 
which are normal function calls, the initializa¬ 
tion code is placed before the generator func¬ 
tion. For example, (Seq (oscil :freq 440)) is ex¬ 
panded into: 17 

(let ((generatorO (let ((varO (make_oscil_ 440 0.0))) 
(lambda (kont) 

(kont (oscil_ varO 0 0)))))) 

(lambda (kont) 

(generatorO kont))) 


17 Since the Snd-RT preprocessor doesn’t know the 
number of arguments for normal functions such as osciL, 
this expansion requires the preprocessor to know that 
this particular Seq block has 0 inputs. The preprocessor 
should usually get this information from the code calling 
Seq, but it can also be defined explicitly, for example like 
this: (Seq 0 Cut (oscil :freq 440)). 




10.3 The Soft Synth using CPS Sound 
Generators 


(define-stalin (Reverb) 


(Seq (all-pass 
(all-pass 
(all-pass 
(all-pass 
(Sum (comb 
(comb 
(comb 
(comb 

(delay :size 


:feedback - 
:feedback - 
:feedback - 
:feedback - 
scaler 0, 
scaler 0, 
scaler 0, 
scaler 0, 
(* .013 


0.7 :feedforward 0. 
0.7 :feedforward 0. 
0.7 :feedforward 0. 
0.7 :feedforward 0. 
742 :size 9601) 

733 :size 10007) 

715 :size 10799) 

697 :size 11597)) 
(mus-srate))))) 


7) 

7) 

7) 

7) 


(define-stalin (Stereo-pan c) 

(Split Identity 
(* left) 

(* right) 

:where left (* sqrt2/2 (+ (cos angle) (sin angle))) 
:where right (* sqrt2/2 (- (cos angle) (sin angle))) 
:where angle (- pi/4 (* c pi/2)) 

:where sqrt2/2 (/ (sqrt 2) 2))) 


(define-stalin (softsynth) 

(while #t 

(wait-midi :command note-on 
(define tone 
(gen-sound 

(Seq (oscil :freq (midi->hz (midi-note))) 

(* (midi-vol)) 

(Stereo-pan (/ (midi-note) 127))))) 

(spawn 

(wait-midi :command note-off :note (midi-note) 
(stop tone)))))) 


(define-stalin (Fx-ctrl clean wet Fx) 
(Sum (* clean) 

(Seq Fx 

(* wet)))) 


(<rt-stalin> 

(gen-sound 

(Seq (In (softsynth)) 

(Par (Fx-ctrl 0.5 0.09 (Reverb)) 

(Fx-ctrl 0.5 0.09 (Reverb)))))) 


11 Adding an ADSR Envelope 

And finally, to make the MIDI soft synth sound 
decent, we need to avoid clicks caused by sud¬ 
denly starting and stopping sounds. To do this, 
we use a built-in ADSR envelope generator (en¬ 
tirely written in Scheme) for ramping up and 
down the volume. Only the function softsynth 
needs to be changed: 


ming. 
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